
N95- 17196 


A PROCESSING CENTRE 
for the CNES CE-GPS experimentation 

Norbert SUARD - Jean-Claude DURAND 

C.N.E.S. - CT/TI/PS/AP & SDS/SM/ES 
18 av. E. Belin 

31055 TOULOUSE Cedex - FRANCE 




ABSTRACT 

CNES is involved in a GPS (Global Positioning 
System) geostationary overlay experimentation. 
The purpose of this experimentation is to test 
various new techniques in order to select the 
optimal station synchronization method, as well as 
the geostationary spacecraft orbitography method. 
These new techniques are needed to develop the 
Ranging GPS Integrity Channel services. 

The CNES experimentation includes three 
transmitting/receiving ground stations 
(manufactured by IN-SNEC), one INMARSAT II 
C/L band transponder and a processing centre 
named STE (Station de Traitements de 
l’Experimentation). 

Not all the techniques to be tested are 
implemented, but the experimental system has to 
include several functions; part of the future system 
simulation functions, such as a servo-loop 
function, and in particular a data collection function 
providing for rapid monitoring of system 
operation, analysis of existing ground station 
processes, and several weeks of data coverage for 
other scientific studies. 

This paper discusses system architecture and 
some criteria used to its design, as well as the 
monitoring function, the approach used to develop 
a low-cost and short-life processing centre in 
collaboration with a CNES sub-contractor (ATT- 
DATAID), and some results. 

Keywords : Ground System, Architecture, 
Software. 
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1. INTRODUCTION 

The GPS system offers exceptional qualities 
(accuracy and worldwide coverage). But for civil 
aviation (see (1)), this system has three major 
drawbacks : 

- insufficient integrity, 

- limited availability, 

- voluntary spatio-temporal degradation. 
Ranging GPS Integrity Channel services (RGIC) 

should enable GPS to be used by civil aviation. 

The experimentation prepared by CNES (see (2)) 
is dedicated to the technical validation of the 
Ranging GPS Integrity Channel concept that 
always needs : 

- station synchronization better than 10 ns, 

- GPS-type signals transmitting, 

- geostationnary spacecraft orbitography 
better than 10 meters. 

The CE-GPS (European complement to GPS) 
experimentation includes a master ground station 
transmitting a GPS -type signal to an INMARSAT 
2 geostationary satellite. The repeater broadcasts 
this signal in L-band -to the master station and to 
the other stations. These also have receiving and 
transmitting facilities for GPS -type signals. 

Each ground station includes a computer and 
software to : 

a) record broadcasted and raw data from several 
facilities, 

b) process some of the data in a real time loop 
(0.6 seconds) to generate transmitting signals 
correctly, 

c) control and monitor equipment, 

d) make some of the data available to the 
processing centre. 

Other data (such as orbital and some weather 
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parameters) required to drive the system or for 
various scientific studies are centralised at the 
processing centre. 

The functions of the processing centre (STE) are 
to : 

a) prepare data for ground operation control 
station schedules, 

b) collect data from ground stations and other 
sources, 

c) archive and distribute these data to different 
scientific teams, sometimes after specific 
processing, 

d) monitor ground station operations. 



2. ARCHITECTURE 

In this chapter, the architecture of the ground 
station and of the STE are presented. 

After, an overview of the exchange system is 
given, then criteria used to distribute software 
between ground station, processing centre and 
scientific centres are listed. 


2.1 Grou nd stations architecture 

Each ground station is composed with multiple 
equipments connected to a main computer. All 
software ground station functions are centralized at 
this computer 



figure 2 : Ground station overview 
2,2. processing centre architecture 



media types to distribute data 


figure 3 : external links 
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The processing centre software architecture is 
decomposed in two blocks of functions (figures 4 
& 5 below). These two blocks can be used 
together. 

The diagram below shows functions that are only 
used when data are collected. 
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figure 4 : software architecture (1) 

The diagram below shows functions that are only 
used when data are pre-processed and sent to a 
scientific centre. 



external software (at scientific centres) 


figure 5 : software architecture (2) 


These different functions are activated and 
controlled through a man-machine interface 
displaying four main windows : 

1) Function selection, after which a sub- 
function menu is displayed for input of 
various parameters. 

2) Display of the number and type of tasks 
currently running. 

3) Output of task messages. 

4) System message output (console). 

Other windows are available with OPENLOOK 
SUN system tools (file manager, calctool, 
cmdtool, etc.) and may be selected by the operator 
when required. 

The diagram below shows the hardware 
architecture used to support the different functions. 



figure 6 : hardware architecture 

PC/MS-DOS and DEC/VMS are only used to 
product adequate media for specific scientific 
centres. 


2.3. exchange system 

The system may use different configurations, 
with one, two or three ground stations. For 
example, this system was operating at the end of 
1993 with two ground stations (Toulouse and 
Paris) but is operating with three in 1994 
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(Toulouse, Kourou in French Guyana and 
Hartebeesoek in South Africa). 

As ground station locations might vary according 
to use with a different network at each 
configuration, the interfaces between ground 
stations and the processing centre had to be 
standardised and easily modified, so data- 
files are used for exchange between the processing 
centre and a ground station. 

Thus, when a network is available, FTP (File 
Tranfer Protocol) is used to exchange subsets of 
data- files, QIC 6150 data-cartridges are used to 
tranfer the remaining data-files. 

Else (when no network is avalaible : for example 
tranfer from one development site to another) all 
data can be saved and easily transported by using 
only cartridges. 

This rule was also applied for the other 
exchanges between the processing centre and the 
scientific centres. Computers are not homogeneous 
between the processing centre and the scientific 
centres, so data in files are in ASCII format. 

Each file tranfer is initiated by the STE processing 
centre. 


2,4. Cr iteria for the distribution of software 
between ground stations and processing centre 

In the operational phase, if one of the 
components were to fail (processing centre, 
ground station or network), the system would have 
to ensure that any data generated by the other 
components was not lost, but without relying 
on any redundant facilities. 

As ground stations include a real-time loop to 
generate GPS-type signals, it was decided that the 
main processing system in each ground 
station should receive each function with 
real-time constraint, and thus should collect all 
data from all facilities through RS232 or IEEE 
links, even though the processing centre would be 
able to obtain data through a different link. 

This provided an uniform means of data 
exchange between any ground station and the 
processing centre. 

So, with the data-file exchange system, each 
ground s tation computer would then manage short- 
term file-saving (over a few days), while the 
processi ng centre would manage long-term 


archiving for all ground stations and all system 
configurations used. 

One of the aims was to cut down manual 
operations in ground stations so that they would 
not need to be staffed on a permanent basis. 

All operations where data has to be keyed in 
manually are carried out in the processing 
centre, and the results file is then transmitted to 
the ground station (before the operational phase, 
data may be input with a text editor as the data in 
these files is in ASCII format). 

NB : The only manual operation needed under 
normal station operating conditions is a twice- 
weekly cartridge change. 

Another point we observed was to avoid 
allocating to ground stations any 
processing occurring at irregular intervals 
as site and azimut angles processing, so that real- 
time loops would not be affected by a random load 
peak. 

Any such processing is carried out at the 
processing centre and gives results files that are 
valid over the whole operational period and 
transmitted. 

The ground station software only uses indirect time 
and date addressing to retrieve data when needed. 


2,5, Criteria for the distribution of software 
between processing centre and scientific centres 

The first criterion was to avoid imposing 
specific types of equipment on scientists 
configuration. Hardware for data exchange was 
defined for each scientific centre for its own data, 
STE processing centre which would be responsible 
for setting up a hardware and software 
configuration based on existing facilities at CNES. 

The second criterion was to develop and operate 
at the processing centre any data pre-processing 
software which would be common to at 
least two scientists. 

The third criterion was to keep options open 
for specific software to be set up within 
the processing centre to enable the operator to 
pre-process also scientific data, as the processing 
of raw data to obtain interpretable results can 
otherwise be very time-consuming for the 
scientists using them. 
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3. THE MONITORING FUNCTION 

Station monitoring from the processing 
centre is not carried out in real time, for 

several reasons : 

1 ) equipment is more and more reliable ; 

2) operator at processing centre is only present 
5 days per week, 8 hours per day even if 
each ground station is operational 7 days/7, 
24 hours/24; 

3) the loss of a few data-days is not a problem, 
but when the data collection function is 
operating, we have to be certain that the data 
is correct. 

To meet this requirement, ground station 
software stores three types of data in monitoring 
files. 

The first type is made up of raw data extracts, the 
second of extracts of equipment command data 
received and distributed by the servo-loop 
mechanism, while the third type consists of 
monitoring indicators generated on ground stations 
(watchdog function for the various flows of 
expected data, quality indicators for INMARSAT 2 
satellite links as bit error rates, etc.). 

These monitoring files are processed by 
dedicated software at the processing centre using 
simplified equations to describe observable 
phenomena. The operator can then display the 
resulting parameters in graph form. The curves 
change colour if values exceed monitoring 
thresholds, which take into account the 
simplifications in the equations. 

The observable phenomena are : 

- master or slave servo-loop, 

- pseudorange and carrier phase measurements for 
pseudo random codes (1 to 32 : GPS constellation, 
33 to 36 : back up for GPS, used in the CE-GPS 
experimentation, 

- pseudorange residues, 

- vertical Total Electron Content, 

- two-way time transfer through INMARSAT 2, 

- INMARSAT2/ground station link indicators. 


4. APPROACH USED IN STE 
DEVELOPMENT 

The processing centre software was to be written 


by a specialised firm, and to have it ready on 
schedule (development began in November 1992 
for partial implementation at the end of March 
1993), without the constraints involved in 
managing too large a team, the following 
considerations were applied. 

1) As the processing centre would be operating 
for no more than 2 years, the normal rules of 
management were made more flexible. The 
alterations mainly concerned reviews at the end of 
each development phase and the documents to be 
managed within the configuration. For this 
processing centre, key-points with only the CNES 
and ATT-DATAID technical managers present 
were substituted for all reviews. This rule 
remained valid as long as no major differences 
arose between ATT-DATAID and CNES. 

2) A study was carried out before the contract 
was signed, to assess the possibility of including 
existing products to meet requirements for all 
or some of the functions needed. Such products 
would be incorporated by adapting the new 
software packages to the interfaces. The functions 
delivered to ATT-DATAID thus included graph- 
plotting (developed in PV-WAVE command 
language), orbit computation functions for the 
geostationary and GPS satellites and computing 
routines for tropospheric delay factors. 

3) Whenever existing low-cost hardware 
could be used to resolve a particular 
problem, this was acquired in preference to the 
development of specific software. For example, an 
additional 2 gigabit disk for file management was 
acquired instead of developing a file management 
system with existing compacting and decompacting 
tools, as the purchase price of the disk was 
equivalent to only a few days of software 
development. 

4) File name specifications were set out from 
the start of the experimentation system definition 
phase, as well as the choice of the operating 
system for the main computers (UNIX) and a 
recommendation on the content of all files 
(ASCII). This enabled processing to be carried out 
with tools which were incorporated within 
the operating system and which were therefore 
easy to manipulate with "shell-scripts". The same 
reasoning was applied to the development of 
software for the ground stations. 
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5) A large number of parameters was 
incorporated into the processing centre software, 
either within configuration files to be handled by 
the text editor or as data to be keyed in through the 
man-machine interface. This last solution does not 
affect costs as the centre is permanently staffed 
(except at weekends) during system use. 

6) In order to maintain autonomy between 
functions and to avoid over-automation of 
the processing centre, some data input is 
earned out by the operator even where such data 
can be deduced from available data in the 
processing centre. 

7) The software for the processing centre was 
delivered in several stages : 

- Stage 1 : man-machine interface ; 

- Stage 2 : all data collection functions 

(see figure 4) ; 

- Stage 3 : all data distribution with scientific data 

pre-processing ; 

- Stage 4 : incorporation of specific processes 

when requested by a scientist. 

This method enabled real progress in processing 
definition to be monitored without the need to 
program everything in advance. 

Tasks were therefore not scheduled in the usual 
sequence for this type of development (definitions 

- specifications - realization). 

This is not always advantageous (project 
management is more demanding), but the final 
product is better matched to the real needs of 
different users. 


5. SOME RESULTS 
5.1. about STE software 

ATT-DATAID supplied 230 working days to 
write the processing centre software, starting on 
the 2nd November 1992 and ending with Stage 3 
acceptance tests which were carried out on the 21st 
of April 1993. 

For the STE project, the CNES work-load over the 
same period amounted to 70 days. 

The software for this processing centre 
comprises 17 000 lines of source code without 
annotations (in FORTRAN, C, awk, shell), of 
which 4 000 were supplied by CNES. Certain 
functions were also directly supplied by CNES as 
binary codes. 


Anomaly report number was : 

16 after acceptance testing ; 

29 after technical approval from the processing 
centre ; 

34 at the beginning of the CE-GPS 
experimentation ground segment operational use 
with 2 ground stations (Toulouse and Paris) ; 

47 on close of this operation. 

Other scientists had access to the data collected, 
although they were not identified at the beginning 
of the project. 

They required no specific processing. To enable 
the system to produce and distribute their data, 
declarative instructions were input into the 
parameter files then tested (1 day work load). 

5.2. ab out STE/ground stations operations 

The fact that STE is not staffed at weekends is 
just acceptable to detect a problem at a ground 
station, because the delay between the origin of a 
problem and its repair can be several days. 

So, for a non experimental system, redundant 
facilities in ground station seem needful, operator 
should choice correct data. According the interrupt 
time acceptable by a mission of data collection, 
other solutions are possible (call by phone the 
operator after a detection of a problem, processing 
centre staffed at week-end, ...) 
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